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ABSTRACT 


This thesis will focus directly on the enhancement of 
an established Network Operations Center (NOC) and will 
extend the capabilities of this asset beyond its present 
scope. By defining the current infrastructure using 
present network management tools it will provide a better 
understanding of the present network, as well as enhance 
management for future field experiments. Finally, 
extending the CENETIX network via implementation of Virtual 
Private Networking (VPN) technology will allow other 
experimental labs who currently utilize the Defense 
Research Engineering Network (DREN) , such as the Lawrence 
Livermore National Laboratory (LLNL), Biometrics Fusion 
Center (BFC), Defense Threat Reduction Agency (DTR), Office 
of Force Transformation (OFT), Coast Guard station (located 
in Alameda), various other US allied forces. Oversea 
Partners, etc.) access to current and future field 
experiments. 
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CENETIX LAB HISTORY 


I. 

A. BRIEF HISTORY OF CENETIX LAB 

The Center for Network Innovation and Experimentation 
(CENETIX) has gone through multiple changes since its 
inception in 2001. These changes have been productive in 
supporting advanced studies of wireless networking and 
unmanned vehicles by providing a means for students to 
perform hands-on thesis research during their studies while 
at NPS. 

CENETIX has its beginning in developing and testing 
un-manned aerial vehicles (UAV) which would improve the 
capability of rescuing downed pilots, to conducting 
surveillance, targeting and acquisition networking (STAN). 
From that, the CENETIX testbed facility has evolved to a 
more robust quarterly experimentation cycle which focuses 
on emerging collaborative architectures as well as adaptive 
management of sensor-unmanned vehicle networks. 

The CENETIX testbed continues where the Global 
Information Grid Applications (GIGA) Lab has conducted 
exercises in past Tactical Network Topology (TNT) 
experiments. External agents who have participated or are 
working directly with faculty and students include: 
Lawrence Livermore National Lab (LLNL), Biometrics Fusion 
Center (BFC), Massachusetts Institute of Technology (MIT), 
Stanford University, University of California - Santa 
Barbara (UCSB), and various military agencies (both U.S. 
and allied) around the world. Currently operations at Camp 
Roberts and the Naval Post Graduate School locations have 
been limited to a geographic area, and have presented 
limitations for those external agencies who wish to 
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participate. The need for those external agencies the 
ability to control, observe and participate in future 
experiments is critical to the success or any new concepts 
to be tested. 

These past experiments conducted from the CENETIX test 
facilities have proven vital to various Department of 
Defense (DoD) agencies, combatant commands, and various 
international allies. This interest has transpired to 
funding by these agencies, and will continue to allow both 
faculty and students the opportunity to conduct future 
experiments with the needs of the customer in mind. 
Currently the primary funding agencies for the CENETIX 
testbed facility include: 

• CDTEMS (Congressional Funding): FY03 = $1M, 

FY04=$2M, FY05=$1.75M 

• USSOCOM: FY05 = $1. 96M (Light Reconnaissance 

Vehicle), FY06 (JMUST) 

The establishment of a testbed facility, located at 
Naval Post Graduate School (NPS), which could be utilized 
by both the trainer and the student, provides a tremendous 
opportunity to develop, test, and enhance new technologies 
that are required in the changing tactical environments of 
the 21 st Century. From its inception the CENETIX testbed 
has maintained three primary objectives: 

• Provide an opportunity for NPS students and 
faculty to demonstrate and evaluate their latest 
technologies in an operational environment and 
provide the operational community the opportunity 
to utilize and experiment with these 
technologies. 

• Take advantage of operational experiences of NPS 
students. 

• Provide the Military, National Laboratories, DoD 
Contractors, and Universities the opportunity to 
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test and evaluate latest S&T in operational 
environment; small, focused field experiments 
with well-defined measures of performance 

B. HOW CENETIX COMMUNICATES 

CENETIX is based aboard NPS in Monterey, California 
and maintains the Global Information Grid Applications and 
Operations Code Lab (GIGA Lab). Through the efforts of NPS 
faculty, staff, and students, CENETIX implements an 802.16 
Orthogonal Frequency Division Multiplexing (OFDM) wireless 
network connecting CENETIX facilities within the Monterey 
Area to experimentation facilities located about one 
hundred miles to the south at the Camp Roberts National 
Guard Base. 



Figure 1. TNT Network Plan 

This backbone connection of the network, along with 
connections to facilities at the beach laboratory in 
Monterey, the Center for Interdisciplinary Remotely Piloted 
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Fort 


Aircraft Studies (CIRPAS) in Marina, California, 

Hunter Liggett, the Military Operations in Urban Terrain 
(MOUT) facility at Fort Ord, U.S. Coast Guard facilities in 
San Francisco Bay, and Avon Park, Florida along with 
additional ground, air, and maritime locations, allows for 
a collaborative test-bed that provides a multi-theater C2 
structure supporting missions and objectives of the CENETIX 
research team. The overall mission is to support advanced 
studies of wireless networking with unmanned aerial, 
underwater, and ground vehicles in order to provide 
flexible deployable network integration with an operating 
infrastructure for interdisciplinary studies of 
multiplatform tactical networks. Global Information Grid 
connectivity, collaborative technologies, situational 
awareness systems, multi-agent architectures, and 
management of sensor-unmanned vehicle-decision maker self¬ 
organizing environments. 

The CENETIX testbed supports the following areas of 
research, where students and faculty alike can find their 
niche in testing and implementing the new concepts that 
will change the battlefield of the future. Specific areas 
of interest where students, staff and partners have 
participated: 

• Adaptive wireless sensor-unmanned vehicle- 
decision maker networks. 

• Ad hoc wireless mesh networks. 

• Global Information Grid applications 

• Network operations and Command Centers. 

• Collaborative technology. 

• Shared-situational and network awareness 
technology. 

• Self-organizing network-centric environments. 
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• Multiple-agent intelligent systems. 

• Satellite, ultra-wideband, and RFID 

communications. 

C. CENETIX AND VPN SOLUTION 


The 

future 

of the CENETIX 

Testbed 

will 

incorporate a 

Virtual 

Private 

Network (VPN) 

solution 

that 

will allow a 

global presence 

where multiple 

personnel 

and 

organizations 


can participate during future TNT experiments. These 
personnel and organizations include: Biometrics Fusion 
Center (BFC), Office of Force Transformation (OFT), 
Lawrence Livermore National Laboratory (LLNL), Defense 
Threat Reduction Agency (DTR), Coast Guard Station 
Alameda (CGSA), as well as various allies both in the 
Continental U.S. and abroad where personnel in countries 
like Austria, Sweden, and Singapore have expressed a desire 
to participate. 

These sites will incorporate either a hardware device 
(Cisco 3000 Series Concentrator), or a software solution 
(Cisco VPN Client) to perform reach-back capabilities to 
the Cenetix Testbed network located in the Network 
Operations Center onboard Naval Post Graduate School, 
Monterey, California. 

The benefits of a VPN solution which will provide a 
secure means for all participants to be fully integrated in 
future TNT experiments will prove beneficial. The ability 
to collaborate amongst colleagues with various backgrounds 
and experiences will only serve to enhance these 
experiments. 
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II. VPN OVERVIEW 


A. WHY DO WE NEED A VPN SOLUTION? 

In today's interconnected world, the need to move 
information from site to site is becoming common. Whether 
this move is from one end of town to the other or across 
the globe, the basic challenge is the same: How can we 
securely transport our data? For many years, this 

transportation was accomplished with expensive proprietary 
links that were leased from communication vendors so that 
companies had a "private" segment for such communications. 
The longer the distance, the more these connections costs, 
making wide area networks (WANs) a luxury that many firms 
could not afford. At the same time, many firms could not 
afford to go without them. As broadband Internet 

connections became staples for many firms, the concept of 
using the existing structure of the Internet as WAN cabling 
became an intriguing one. Costs could be greatly reduced 
using these already available public access points. The 
concern again was how to keep the data secure. Because we 
are sharing an international "party line" with anyone else 
who connects to the Internet, how can we be sure that our 
data is protected from eavesdropping, manipulation, un¬ 
authorized users, etc? The solution is Virtual Private 
Networking. (Zeltser, 161) 

As we have seen VPNs were developed initially to deal 
with security issues of transmitting clear text data across 
a network. Clear text data is information that can be 
examined and understood by any person, including the 
source, destination, and anyone in between. Examples of 
applications that send traffic in a clear text format are 
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Telnet, file transfers via FTP, or TFTP, email using the 
Post Office Protocol (POP) or Simple Mail Transfer Protocol 


(SMTP), and many others. (Deal, 6) 

Why do we need VPNs? There are a host of unethical 
individuals, such as hackers, who can take advantage of 
applications that send clear text data to execute the 
following type of attacks: 

(1) Eavesdropping. 

a. This is the most common type of attack with 
clear text. 

b. A person examines the contents of packets as 
they are transmitted between two devices. 

c. Both applications and protocols are 

susceptible to this type of attack, these 
include: Telnet, POP, HTTP, TFTP, FTP, SNMP. 

i. Tools: 

1. A protocol analyzer is used to 

sniff packets, on a PC with a 
promiscuous network interface card 
(NIC). The attacker must have 
access to a connection between the 
actual source and destination 
devices. 

ii. Solution: 

1. One way to overcome eavesdropping 

attacks is to use what e-Commerce 
company's use, HTTP with SSL 
(HTTPS) to encrypt user-sensitive 
information. 



2 . 


Another solution is to incorporate 
a VPN solution with encryption. 
The encryption will scramble the 
clear text information into what 
would appear as a random string of 
characters; only the destination 
will be able to decipher the 
information. The following two 
methods are implemented in a VPN 
solution: 

a. Link Encryption - the entire 
frame is encrypted between 
point-to-point connections. 

b. Packet Payload Encryption 

only the packet payload is 
encrypted, which allows 

Layer-3 network devices to 

route across the Internet. 
This is the most common 
encryption method you will 
see in VPN solutions, because 
of it's scalability across 
multiple hops, only two 

devices need to handle the 

encryption/decryption process 
while the intermediate 

devices simply route the 

encrypted packets. 
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( 2 ) 


Masquerading 


a. This occurs when an individual hides 
their identity, possibly even assuming 
someone else's identity. This is 

accomplished by changing the source 
addressing information in packets. In 
the TCP/IP world this is commonly 
referred to as spoofing and typically 
associated with Denial of Service (DoS) 
and unauthorized access attacks. 

i. Tools: 

1. The attacker would use some sort 

of specialized packet-generating 
program which would allow him to 
specify the source address to be 
used, instead of using the IP 
address associated with the 

hacker's PC NIC. 

2. This would allow the attacker to 
use an internal source address 
that a packet filter might 
allow, and then redirect that 
packet to through the firewall 
to his destination. 

ii. Solution: 

1. The most common solution is to 
use a packet integrity check 
system, which is implemented 

with a hashing function. 
Hashing functions allow you to 
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verify the source of transmitted 


packets. Because hashing 

functions use a one-way hash 
with a shared key, only the 
devices that have the key will 
be able to create and verify the 
hash values. With VPNs, the 
most common hashing functions 
used are MD5 and SHA. 

(3) Man-in-the-Middle 

a. This type of attack can take on many forms, 
of which there are two common attacks: 

i. Session Replay 

1. An attacker, sitting between two 
devices, captures the packets from 
the session. The attacker will 
then try to use the captured 
packets at a later time by 
replaying (resending) them. 

2. The attacker's goal is to gain 
access to the remote system with 
the same packets by changing the 
contents of the packets to assist 
in the process. 

ii. Session Hijacking 

1. An attacker will attempt to insert 

himself into an existing 

connection and then take over the 
connection between the two 

devices. 
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2. To execute this attack, the 

attacker will have to perform 

masquerading, where the attacker 
is pretending to be the source and 
destination devices. Plus, the 
attacker must have access to the 
packets flowing between the source 
and destination devices. 

a. Tools: 

i. Attackers will most 

commonly use an attack 
protocol analyzer to 
capture packets with the 
two types of attacks. 

ii. However with Session 
Replay attack, the 

hacker might use Java or 
Active X scripts to 
capture packets from a 


web server. 

And, with 

Session 

Hijacking 

attack, the 

attacker 

will need some type of 

specialized 

TCP 

sequence-number 

guessing 

program to successfully 

intercept and 

take over 

an existing TCP 


connection. 
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Solutions : 


b. 

i. The most common way to 
solve these types of 
attacks would be to 
randomize the TCP 

sequence numbers, which 
would make it nearly 
impossible for the 
attacker to predict 
future sequence numbers 
for the session. This 
is possible due to the 
32 bit length sequence 
number which has over 2 
billion possible 

combinations. 

ii. Another solution would 
be to incorporate a VPN 
solution. With VPNs 

three are utilized to 
combat man-in-the-middle 
attacks: 

1. Device 
Authentication 

2. Packet Integrity 
Checking 

3. Encryption 
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B. 


WHAT IS A VPN? 


The Internet possesses an unbelievable potential to 
facilitate e-commerce (both in the civil and military 
arena), however a few significant awkward impediments ought 
to be resolved in case an enterprise has to genuinely 
undertake real-time commercial activities across the 
Internet. The Internet's biggest advantages are its 
boundlessness and its universal availability. Yet these 
features are the medium's biggest vulnerability, as stated 
previously. 


When researching what a VPN is and how it functions, 
you will arrive a multitude of definitions, functions, 
capabilities and proprietary terms. But, in the simplest 
terms a VPN is a connection that is established over an 


existing "public" or shared infrastructure using encryption 
and authentication technologies to secure its payload 
between two entities that are not necessarily directly 
connected. However, a good VPN solution will deal with 
most, if not all, of the following issues: (Deal, 12), 
(Zeltser, 161) 

• Protecting data from eavesdropping by using 
encryption technologies such as RC-4, DES, 3DES, 
and AES. 


• Protecting packets from tampering by using packet 
integrity and hashing function such as MD5 and 
SHA. 

• Protecting against man-in-the-middle attacks by 
using identity authentication mechanisms, such as 
pre-shared keys or digital certificates. 

• Protecting against replay attacks by using 
sequence numbers when transmitting protected 
data. 
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• Defining the mechanics of how data is 

encapsulated and protected, and how protected 
traffic is transmitted between devices. 

• Defining what traffic actually needs to be 
protected. 

C. HOW DOES IPSEC WORK? 

IP Security, or IPsec, is a framework of standards 
that provides the following security features at the 
network layer between two peer devices: 

• Data Confidentiality, Integrity, Authentication 

• Anti-replay detection 

• Peer authentication 

With the CENETIX Lab the use of a device that provides 
network layer protection was at the forefront; protection 
of any IP traffic was required between peer devices, and 
IPsec provides that function. However, the downfall for 
implementing an IPsec VPN solution required the use of 
remote clients to install additional software in order to 
communicate with our VPN concentrator. This was 

accomplished by use of the Cisco VPN Client software, which 
is the same software students utilize for access to the NPS 
ERN wireless network. 

IPSec is defined in Request for Comment (RFC) 2401, as 
well as being associated with a multitude of other 
protocols and standards as mentioned in other RFC's. 
However, the main functions that IPSec provides include: 
(Deal, 90) 

• Data Confidentiality - accomplished via 
encryption to protect data from eavesdropping 
attacks, supported algorithms include DES, 3DES, 
and AES. 

• Data Integrity and Authentication - accomplished 
via HMAC functions to verify packets have not 
been tampered with and are being received from a 
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valid peer; prevention of man—in-the-middle or 
session hijacking attacks. Supported functions 
include: MD5 and SHA-1. 


• Anti-Replay detection - accomplished by use of 
sequence numbers in data packets to ensure that 
replay does not occur from a man-in-the-middle 
device. 


• Peer Authentication - accomplished by use of 

symmetric or asymmetric pre-shared keys or 
digital certificates. 

The two main groupings of standards that IPSec 
utilizes are: 


• Internet Security Association Key Management 
Protocol (ISAKMP) / Internet Key Exchange (IKE) - 
defined in RFC's 2407 and 2408 respectively, 
these standards are utilized to establish a 
secure management connection (Phase 1). 


47 06/06/2006 13:05:23 200 SEV=4 IKE/119 RPT=1 205155.71 182 
Group [205.155.71.182) 

PHASE 1 COMPLETED 

Figure 2. Phase 1 Completion - Series Manager 

• Authentication Header protocol (AH) and 
Encapsulation Security Payload (ESP) - defined in 
RFC's 2402 and 2406 respectively, these standards 
are utilized to establish a secure data 
management connection (Phase 2) . 


57 06/06/2006 13:05:23 270 SEV=4 IKE/120 RPT=1 205155.71 182 
Group [205 155 71.182] 

PHASE 2 COMPLETED (msg»d=d62fdb*b) 

Figure 3. Phase 2 Completion - Series Manager 

1. IPsec Connection Process 

In the establishment of a secure IPsec connection, two 
peers will perform five basic steps. Once these processes 
are properly executed the secure connection will remain in 
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place until either a network failure occurs or either one 
of the peers terminates the link. A brief description of 
the processes is as follows: 

(1) The IPsec process is triggered by a pre¬ 

configured station (either remote, or local). 

(2) IPsec will initiate an ISAKMP/IKE Phase 1 
(management connection); no data is being 
transversed. 

a. Phase 1 is responsible for setting up the 
secure management connection, either in the 
main or aggressive mode. 

b. During the Phase 1 process you would find 
the encryption processes (DES, 3DES, AES) 
are being validated, the HMAC function (MD5, 
SHA-1) are implemented, and the pre-shared 
keys are verified. 

c. Uses UDP port 500; this is important if 
utilizing a firewall. If administrators 
fail to establish port 500 access, problems 
will occur when utilizing Network Address 
Translation - Transversal (NAT-T) over port 
4500 . 

(3) IPSec will negotiate the defined security 
parameters (data transform set), and confirm them 
in order to build a secure data connection (Phase 
2 ) . 

a. Phase 2 is responsible for establishing and 
enforcing the security protocols and 
transform for the connection. 
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b. IPsec can use two security protocols to 
protect the data transmitted over the 
connections that are being built. They are 
Authentication Header (AH) and Encapsulation 
Security Payload (ESP), defined in RFC 2402 
and 2406 respectively. 

c. A data transform set contains: the security 

protocol (AH and/or ESP, connection mode 
(tunnel or transport), encryption 

information (DES, 3DES, AES-12 8/192/256), 
packet authentication and verification (MD5, 
or SHA-1). 

i. These transforms are commonly referred 

to as a Security Association (SA) in 
which all of the necessary security 

components to communicate successfully 

with an IPsec peer are defined. 

(4) HMAC functions will be initiated and devices will 
begin to share user data securely. 

(5) Connection is properly made, data is transversed; 

the management and data connections will remain 
in place until administrative requirements are 
reached (lifetime limits, network and user 

requirements). 

2. IPsec and Firewalls 

There are two basic ways VPN traffic is terminated in 
networks: on a firewall, or a device that is behind a 
firewall. In order to properly configure a IPsec tunnel 
through a firewall, the following needs to be configured on 
the device that is providing perimeter security. 
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As we experienced in the Coast Guard Station - Alameda 
location, the following configurations are required for 
firewall devices (Deal 126-127): 


D. 


• Management Connections: UDP port 500 

• Data Connections using AH: protocol 51 

• Data Connections using ESP with no NAT-T: 
protocol 50 


• 

Data 

4500 

Connections 

using 

ESP 

with NAT-T: UDP 

port 

• 

Data 

Connections 

using 

ESP 

with IPsec over 

UDP : 


UDP port 10000 
changed) 

(default 

setting, but can 

be 

• 

Data 

Connections 

using 

ESP 

with IPsec over 

TCP : 


TCP 

port 10000 

(default 

setting, but can 

be 


changed) 

• During pre-test configurations which simulated 
the CGSA equipment string, the following figure 
indicates the final settings for my router. From 
my home, I was able to construct a circuit which 
provided a NAT-T VPN tunnel to the tnt06vpn 
concentrator located on NPS. 

WHAT DEVICE DID WE USE TO ESTABLISH A VPN? 


There are many options to implement a VPN solution, 
such as a PIX or ASA router. The Cisco VPN 3000 Series 
Concentrator offers the best-in-class remote-access VPN 


device that provide businesses with unprecedented cost 
savings through flexible, reliable, and high-performance 
remote-access solutions. Cisco acquired Altiga, which 
initially built the VPN hardware appliances in 2000, and 
have developed the VPN 3000 Series concentrators to provide 
solutions for the most diverse remote-access deployments by 
offering both IP Security (IPSec) and Secure Sockets Layer 
(SSL)-based VPN connectivity on a single platform. 
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There are six different classes of the Cisco 3000 
Series concentrators, use of the 3005 and 3015 were 
preferred for use in the CENETIX Lab. The following table 
depicts a comparative of all six models. 



Cisco VPN 
3005 

Cisco VPN 
3015 

Cisco VPN 

3020 

Cisco VPN 

3030 

Cisco VPN 

3060 

Cisco VPN 

3080 

Simultaneous IPSec Remote 

Access Users^ 

200 

100 

750 

1,500 

5,000 

10,000 

Simultaneous WebVPN (Clientless) 
Users^ 

50 

75 

200 

500 

500 

500 

Maximum LAN-to-LAN Sessions 

100 

100 

250 

500 

1,000 

1,000 

Encryption Throughput 

4 Mbps 

4 Mbps 

50 Mbps 

50 Mbps 

100 Mbps 

100 Mbps 

Enciyption Method 

SW 

SW 

HW 

HW 

HW 

HW 

Available Expansion Slots 

0 

4 

1 

3 

2 

0 

Enciyption (SEP) Module 

0 

0 

1 

1 

2 

4 

Redundant SEP 



Option 

Option 

Option 

Yes 

System Memory 

32/64 MB 
(fixed) 

128 MB 

256 MB 

128/256 MB 

256/512 MB 

256/512 MB 

Hardware Configuration 

111 

Scalable 2U 

Fixed 2U 

Scalable 2U 

Scalable 2U 

Fixed 2U 

Dual Power Supply 

Single 

Option 

Option 

Option 

Option 

Yes 

Client License 

Unlimited 

Unlimited 

Unlimited 

Unlimited 

Unlimited 

Unlimited 


Table 1. 3000 Series Concentrator Comparison (From: 

Deal, 182) 

As you can see, the Cisco 3000 Series concentrators 
are a robust piece of equipment, however depending upon 
your VPN solution and the capabilities that you desire the 
Concentrator is not the only solution. 

Cisco has three platforms choices for L2L sessions: 
Concentrators, Routers, and Private Internet Exchange (PIX) 
and Adaptive Security Algorithm (ASA) security appliances. 
Although the Concentrator does not possess the same 
capabilities of the other devices listed (limited routing 
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functions, limited QoS support, and limited address 
translation to name a few), it's main advantage which is 
why we utilize this device in the CENETIX Lab is it's 
simplicity in configuring L2L sessions. Furthermore, due 
to the size (rather small) of the CENETIX Testbed Network a 
concentrator is ideal in that it is not complicated to 
administer. 

The product of choice for the CENETIX Lab is the Cisco 
3015 VPN Concentrator, see figure below. When comparing 
the other models available, the 3015 provided the most 
favorable solution in scalability, system memory, and the 
amount of clientless remote user access. (Table 1) 



Figure 4. Cisco 3015 VPN Concentrator 

E. WHERE WE INSTALLED VPN DEVICES? 

The reach of the TNT Experiments extends beyond the 
Naval Post Graduate grounds is essential to fully 
integrate, not only the primary agent (SOCOM) but those 
organizations throughout the United States as well, with 
future plans to extend L2L VPN tunnels with allied forces 
in both the European and Asia-Pacific theaters. During TNT 
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06-2 the primary participants included: the Biometrics 
Fusion Center (BFC), Lawrence Livermore National Laboratory 
(LLNL), the Department of Forestry (Missoula), Special Ops 
Command (Avon Park), Northern Command (Northcom), and Coast 
Guard Station Alameda (CGSA). CENETIX Lab was able to 
purchase 3 Cisco VPN 3015 Concentrators prior to the start 
of TNT 06-2, and a vast amount of coordination with NPS 
ITACS and the above organizations was accomplished before 
commencement of TNT 06-2, on l-Mar-2006. The organizations 
where the Cisco 3015 Concentrator (3015) was installed 
included: BFC, Avon Park, and attempts were made 
unsuccessfully to install at the CGSA. 

Some distant stations did not receive a VPN 

Concentrator; however they were assigned VPN Client 
accounts for access to the TNT network, and afforded the 
same privileges of a IPsec connection. The Cisco VPN 
Client is a VPN remote access client that runs on Microsoft 
Windows PC, Linux PCs (Intel based). Macintoshes (MAC OS 
X) , and Sun UltraSPARC workstations (Solaris) . For both 

the Windows and Macintosh environments, a graphical user 

interface (GUI) is utilized and represented in the 

following figure. 



Figure 5. 
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VPN Client 










F. ADVANTAGES/DISADVANTAGES OF VPN 

Some of the questions that must be considered and 
answered when contemplating a VPN solution include: 

• What is the confidence level of the data you are 
sending? 

• What do I need to protect? 

• What kind of protection is required? 

• What value is placed on the secrecy? 

• How important is it to know the source of 
received data? 

• Is it scalable? 

• What is the cost? 

These questions are only represent a very few that 
could be asked. However, they are some of the more 
important questions that need to be addressed up front. 
First off consider the two alternatives to a VPN solution, 
dedicated lines and the unencrypted Internet. With the 
first alternative, the high cost of a dedicated T1 line 
would be futile in today's realm. The cost of operating 
and maintaining a T1 is like renting a home when you could 
buy a house. The Internet today is robust enough to handle 
most organizational bandwidth requirements. The problem is 
how the organizations utilize the Internet to its utmost, 
while providing protection to their interest. 

To leverage the functionality of the Internet and 
increase the security level of communications, a VPN 
solution is ideal. The encryption would protect the data; 
however it would add a slight burden to the organizations 
network and possibly decrease the bandwidth to a small 
degree. As with most IT solutions, encryption comes at a 
price. The more encryption you require, the more cost you 
are going to incur. 
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The major advantages of a VPN include: Security, 
Deployment Advantages, and Cost Effectiveness. With 
security the three most basic IT requirements are 
considered and implemented in a VPN solution. First, 
confidentiality, to guarantee that no unauthorized 
personnel are going to be able to view your information or 
that the algorithms utilized scramble the private data from 
viewing are the most important aspects of VPNs. Second, 
data integrity, verification of information that is 
received and comparison of that information with hashes or 
digital signatures provides a level of protection through 
encryption and VPN use. Last, authentication, verification 
that the information came from whom it was suppose to, and 
also verifying whoever received that information was 
authorized to receive it. 

Concerning the deployment advantages and cost 
effectiveness of a VPN solution, both the economic 
advantages and ease in utilizing existing infrastructure in 
the installation of a VPN would be evident once the project 
was initiated. Because VPNs can utilize existing 
infrastructures, the need to install new cable for 
connectivity is minimal. This in turn would save in 
installation, operation and maintenance costs. 
Furthermore, VPNs would replace the need for organizations 
to rely heavily upon high-cost, dedicated WAN links. As 
well as remote users, who most probably have broadband 
connectivity at their disposal, would no longer be required 
to utilize a dedicated dial-in phone line. Regardless of 
the network setup, in most cases a VPN can give an 
organization an excellent return on investment and add up 
considerable savings in the long run. (Zeltser, 167-168) 
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The major disadvantages of a VPN include: Processing 
Overhead, Packet Overhead, Implementation Issues, 
Troubleshooting and Control Issues, and Internet 
Availability Issues. Although VPNs provide a significant 
amount of advantages to an organization, there are some 
disadvantages that should be carefully considered when 
pushing a VPN solution. The amount of overhead from the 
additional packets that are transported, as well as the 
additional load on systems and devices in the network 
performing encryption, will degrade the performance of the 
network over time. Two problems experienced during TNT 06- 
2 and 06-3 involved troubleshooting and Internet 
availability issues. Due to the CENETIX Lab being operated 
solely by students and professors, NPS ITACS was hesitant 
to allow full control on the devices that students required 
administrative access during preparations for TNT 06-2. 
During 06-3 in conjunction with CGSA, constructing Internet 
access as well as a secure tunnel to the TNT network was 
challenging. However, with utilizing the functions 
inherent to the Cisco 3015 Concentrator, and NAT-T, a 
solution was constructed. 
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III. OBSERVED EXPERIMENTS 


A. TNT 06-2 

Prior to TNT 06-2, only one VPN tunnel was established 
in previous experiments, to the BFC. The initial 
configuration, Fig-6, was established during TNT 06-1, and 
proved the concept of a VPN solution and the ability for 
external organizations to reach-back into the TNT Network. 
Expanding on these findings, extending the VPN architecture 
to more organizations via a L2L IPSec tunnel was planned 
for and installed prior to TNT 06-2 (Fig-7). 



2 / 21/06 


Figure 6. TNT Architecture prior to TNT 06-2. 

In preparation for the TNT 06-2 Experiment, 
coordination with Mike Williams at the Information 
Technology Assistance Center (ITAC) was crucial. Because, 
CENETIX Lab personnel are predominantly comprised of 
students, administrative privileges to make network changes 
is difficult and when required, the requests for changes 
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are at best second fiddle to normal day-to-day NPS NOC 
operations. However, the assistance and patience of Mike 
Williams, in assisting the CENETIX Lab with network changes 


was nearly completed 
experiment on 27Feb06. 
majority of my time 


prior to commencement of the 
Prior to the start of TNT 06-2, a 
dealt with learning about VPN 


technology, coordination with participating organizations, 
and configuration of the TNT and Avon Park Concentrators. 


The VPN architecture, 
3000 Series VPN Concentrato 
while coordinating with the 
Cisco 3845 router, the TNT 
below figure was designed: 


after the installation of two 
rs at the MSC and Avon Park, 
BFC in the configuration of a 
06-2 architecture shown in the 



Figure 7. 


TNT Architecture TNT 06-2. 
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The number of participants who required VPN access to 
the 06-2 experiment included: The Biometrics Fusion Center 
- West Virginia, Special Operations Command - Avon Park, 
Naval Special Warfare Group One (Mission Support Center) - 
Coronado, and Coast Guard Station - Alameda. These 
locations were configured using the Cisco 3005 and 3015 VPN 
Concentrators with the exception of the BFC who utilized a 
Cisco 3845 Router (vice the 3015 that was provided and 
successfully implemented during TNT 06-1). 



Figure 8. VPN Nodes TNT 06-2 (CONUS). 



Figure 9. VPN Nodes TNT 06-2 (OCONUS). 
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Other organizations (Figs. 7 and 8) who did not have 
the necessary equipment to establish a VPN circuit via 
hardware were provided user accounts in order that they 
could log-in and participant on the nps_tnt_vpnO6 network. 
Again coordinating with Mike Williams at ITAC, we created 
the following accounts (and passwords) for users to log-in 
using the Cisco VPN Client software. Planned users 
included: 


One - Biometrics Fusion Center 

Two - Lawrence Livermore National Laboratory 

Two - Dept of Forestry - Missoula, MT 

Six - Special Ops Command - Avon Park 

Two - Northcom - Colorado 

Two - Sweden 

Two - Austria 

Two - Singapore 


Once the VPN Client accounts were created, they were 
provided the information by means of digitally signed, 
encrypted messages with the necessary information to log-in 
on the nps_tnt_vpnO6 network via a secure tunnel. The 
below screen depicts what the users would have seen once 
they loaded the Cisco VPN Client Software and the necessary 
nps_tnt06_vpn profile on their systems. 
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Figure 10. Cisco VPN Client. 


1. Configuring the VPN Concentrator 
a. Con fi gurati on 

With VPN 3015s, three Ethernet interfaces are 
available, and with the VPN 3005 only two Ethernet 
interfaces are available. When configuring the 
nps_tnt06_vpn, located in ITACS, only two interfaces were 
utilized. Ethernet 1 pointing toward inbound private 
traffic (internal LAN), 131.120.0.10 and Ethernet 2 
pointing to outbound public traffic, 205.155.71.182. When 
configuring the interfaces, you must configure the two 
interfaces that physically connect your network. 


mz 


Save( J Refresh<§> 


Tbs section lets you configure the VPN 3000 Concentrator's network interfaces and power supplies 
In the table below, or in the picture, select and click the interface you want to configure 


Interface 

Status 

IP Address 

Subnet Mask 

MAC Addi ess Default Gatewav 

Ethernet 1 (Private) 

UP 

131 120 0 10 

255 255 255 0 

00 03A0 8A8C DB 

Ethernet 2 (Public) 

UP 

205 155 71 182 

255 255 255 240 00 03 A0 8A 8C DC 205 155 71 177 


Ethernet 3 (External) Not Configured 0 0.0.0 0 0 0 0 

DNS S>IY.MK. 172 20 20 11.172 20 20 12 
DNS Domain Name nps edu 
• Power Supplies 



Figure 11. Cisco 3015 Interfaces TNT 06-2. 
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When 


(1) Configuring Ethernet 

configuring Ethernet ports only one port can be checked as 
Public Interface. As in the case of Ethernet 1, it is not 
checked as public, due to the private IP Adx of 
131.120.0.10. 


Since the public 
makes Ethernet 1 Private, the 
interface. With Private setting 
routed IP packets are allowed. 


box is not checked, this 
default setting for this 
all packets except source- 


[Configuration j Interface* I Ethernet 1 


You are modifying die interface you are using to connect to this device If you make any changes, you will break die 
connection and you will have to restart from the login screen 

Configuring Ethernet Interface 1 (Private). 




General Parameters 

S el 

Attribute | Value 

Description 

o 

Disabled 

Select to disable this interface 

o 

DHCP Client 

Select to obtain the IP Address. Subnet Mask and 
Default Gateway via DHCP 

© 

Static IPAddiessmg 


IP Addiess 

131 120.010 

Mask Enter the IP Address and Subnet Mask for 
this interface 

Subnet Mask 

255.255 255.0 

Public Interface 

D 

Check to make tbs interface a 'public* interface 

MAC Addles* 

00 03A0 8A8CDB 

The MAC address for this interface 

Filtei 

—None— v 

Select the filter for tbs interface 

Speed 

100 Mbps ^ 

Select the speed for tbs interface 

Duplex 

Full-Duplex v 

Select the duplex mode for tbs interface 

MTU 

1580 | 

Enter the Maximum Transmit Unit for tbs interface 
(68 - 1500) 

Public Interface IPSec 
Fi agmeutation Policy 

© Do not fragment prior to IPSec encapsulation, fragment pnor to interface transmission 

O Fragment pnor to IPSec encapsulation with Path MTU Discovery (ICMP) 

O Fragment pnor to IPSec encapsulation without Path MTU Discovery (Clear DF bit) 


Interface Configuration Ethernetl. 

(2) Configuring Ethernet 2. Interface is 
set to Public - Allows inbound and outbound tunneling 
protocols plus ICMP and VRRP, fragmented IP packets, and 
drops everything else, including source-routed packets. 

The distant stations (BFC, AvnPrk, and MSC) 
would need to ensure that 205.155.71.182 is configured on 
their systems as the public interface; otherwise the L2L 
connection will fail with our 3015. 


Figure 12. 
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mnasmiBSSEnisas^^H 

Configuring Ellirmrl Iiitriface 2 (Public). 


Genofdl J RIP ' 


General Parameter* 

Sel 

Attribute | Value 

Description 

O 

Disabled 

Select to disable tbs interface 

o 

DHCP Client 

Select to obtain the IP Address, Subnet Mask and 
Default Gateway via DHCP 

® 

Static IPAddiessing 

Select to configure the IP Address and Subnet 

IP Addles* 

205155 71 182 

Mask Enter the IP Address and Subnet Mask for 
this interface 

Subnet Mask 

255 255 255240 

Public Interface 

h 

Check to make tbs interface a “pubhc" interface 

MAC Adiliess 

00 03 A0 8A8CDC 

The MAC address for tbs interface 

Filter 

2 Public (Detouli) 

Select the fiber for tbs interface 

Speed 

10/100 outo v 

Select the speed for tbs interface 

Duplex 

Full-Ouplex v 

Select the duplex mode for tbs interface 

MTU 

1500 

Enter the Maximum Transmit Unit for tbs interface 
(68- 1500) 

Public Interface IPSec 
Fi .lamentation Pobcy 

® Do not fragment prior to IPSec encapsulation, fragment pnor to interface transmission 

O Fragment pnor to IPSec encapsulation with Path MTU Discovery (ICMP) 

O Fragment pnor to IPSec encapsulation without Path MTU Discovery (Clear DF bit) 


Figure 13. Interface Configuration Ethernet2. 



(3) System 

Information. 

Entering 

the 

VPN 

system 

information, such a 

s, name and 

time will 

assist 

in 

future 

troubleshooting of 

this circuit 

For CENETIX 

VPN 

circuit 

, the assigned name 

is: tnt06vpn. 





Configuration | System | General | Identification 


Configure system identification (optional). These entries are stored in the MTB-II system object. 

System Name tnt06vpn Enter a system name/hostname for the device; e.g., vpnOl 

Contact Enter the name of the contact person 

Location Enter the device location; e.g.. Computer Lab 3 


Configuration | System | General | Time and Date 


Configure the time and date. 

Setting the time on your VPN 3000 Concentrator is very important, so that logging and accounting information is correct. 
The current time on the device is Monday, 13 March 2006 12:21:07. 

New Time 12 [:|21 |:|l2 | March v| / jl3 [ .' 12006 | (GMT-08:00) PST v 

0 Enable DST Support 


Figure 14 

• 

Cisco 3015 

General Configuration. 



(4) 

Configuring 

Tunneling Protocols. 

The 

nps_tnt0 6_vpn 

is 

configured 

using IPsec, L2L. 

When 

initiating a 

sit 

e-to-site session VPN seven steps 

are 

performed in 

the 

establishment 

of a secure session. 

The 


following steps are as follows: 
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One VPN gateway peer initiates a session to the 
remote VPN gateway peer. 

ISAKMP/IKE Phase 1 begins when the peers 
negotiate how the management connection will be 
protected. 

ISAMP/IKE. 

RFC 2407 - Internet Security Association and Key 
Management Protocol (ISAKMP) defines how devices 
communicate with each other via IPsec, defines 
the different kinds of communications and 
acknowledgements (responses), and how IPsec 
communications are packaged into an 
understandable format. 

ISAKMP is a generic key management and security 
association creation protocol for use in TCP/IP 
networks. 

RFC 2409 - Internet Key Exchange (IKE) protocol 
is a hybrid protocol which is responsible for 
negotiating, creating, and refreshing keying 
information to protect IPsec connections. Where 
IKAMP defines the framework, IKE defines the 
mechanics on how the process of dealing with 
keying material accomplished. 

IKE is an implementation of ISAKMP used for IPSEC 
key management. 

Diffie-Hellman is used to share the keys securely 
for encryption algorithms and HMAC functions of 
the management connection. 

Diffie-Hellman Key Exchange addresses this 
problem and Internet Key Exchange (IKE) uses this 
Diffie-Hellman to ensure that a shared key can be 
generated and shared across a public connection 
in a way that is infeasible for anyone to work 
out the key. This shared key can then be used 
with an encryption algorithm such as DES, 3DES, 
IDEA etc. 

RFC 2104 - Hashing Message Authentication Codes 
(HMAC) a subset of hashing functions that 
specifically address the authentication issues 
with data and packets. HMACs are a shared secret 
symmetric key to create the fixed output, called 
a digital signature or fingerprint. 
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• Symmetric Key - use single key to provide a 
security function to protect information. This 
form of keying is very efficient and fast, and 
typically used for encryption and packet 
integrity checking. Typical forms of keying that 
utilize symmetric keying: DES, 3DES, AES. Types 
of hashing functions that use symmetric keying: 
MD5 and SHA. 

• Device authentication is performed across the 
secure management connection. 

• ISAKMP/IKE Phase 1 ends and Phase 2 begins: the 
peers negotiate the parameters and the keying 
information to protect the data connections (this 
is done across the secure management connection 
or, optionally by using Diffie-Hellman again). 

• The data connections are established and Phase 2 

ends: the VPN gateways can now protect user 

traffic across the data connections. 

• Management and data connections will remain 
active until they expire, and must be rebuilt. 

Capitalizing on the security features that 
IPsec utilizes, as well as the security policies that are 
in place at the distant stations (BFC, AvnPrk, MSC) who 
desire to participate in the TNT experiments. It was 
determined that L2L IPsec tunnels provide the best solution 
for the CENETIX testbed to implement. The figure below 
shows the three L2L Sites that were installed, configured, 
and operated during TNT 06-2. Configuration of these three 
circuits required a significant amount of my time in 
coordination with network personnel both here at the NPS 
ITACS NOC, and the distant station NOCs. Although 

challenging, this situation presented the management piece 
of my thesis research. 
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This section lets you configure IPSec LAN-to-LAN connections LAN-to-LAN connections are established with other VPN 3000 
Concentrators, PDC firewalls. 7100/4000 senes routers and other IPSec-compliant security gateways To configure a VPN 3002 
or other remote access connection, go to User Management and configure a Group and User To configure NAT over LAN-to- 
LAN. go to LAN-to-LAN NAT Rules 

Click the Add button to add a LAN-to-LAN connection, or select a connection and dick Modify or Delete 
(D) indicates a disabled LAN-to-LAN connection 


LAN-to-LAN 

Connection Actions 

Amy Biolab Tunnel ( 150 177 145 130) on Ethernet 2 (Public) 

AVON PARK VPN (148 70 235.27) on Ethernet 2 (Public) ___ 

HSC NSVC (144 141 185 2) on Ethernet 2 (Public) | Add | 

[ Modify ] 

| Delete | 


Figure 15. 

IPsec L2L 

Connections TNT 06-2. 


(5) 

Biometrics 

Fusion 

Center (BFC). 

The 

expertise at the 

BFC is utili 

zed in 

the analysis of 

data 


files that the detection teams have gathered. 
Collaboration of users is conducted via the Groove peer-to- 
peer tool. 


Configuration I Tunneling and Sacurlty I IPSoc I LAN-to LAN l Modify 


Modify an IPSec LAN-to-LAN connection 

Enable 0 

Name Army Biolob Tunnel 
Interface Ethernet 2 (Public) (205155 71 182) v 
Conner non Type Br-direchonal v 

150 . 177 . 145.130 


Check to enable this LAN-to-LAN connection 
Enter the name for this LAN-to-LAN connection 
Select the interface for this LAN-to-LAN connection. 

Choose the type of LAN-to-LAN connection An Ongwale-Only 
connection may have multiple peers specified below 


Enter the remote peer IP addresses for this LAN-to-LAN 

Peers connection Onginale-Only connection may specify up to ten peer 

IP addresses Enter one IP address per line 


Digital 

Certificate 


None (Use Preshored Keys) v 


Certificate O Entire certificate chain 
Ti ansuusnon ® Identity certificate only 
Preshared Key M3uWIR739qPoAoV 
Authentication ESP/MD5/HMAC-128 v 
Enciyption 3DES-168 v 
IKE Proposal IKE-3DES-MD5 v 


Select the digital certificate to use 

Choose how to send the digital certificate to the IKE peer 

Enter the preshared key for this LAN-to-LAN connection 

Specify the packet authentication mechanism to use 

Speedy the encryption mechanism to use 

Select the IKE Proposal to use for this LAN-to-LAN connection 


Figure 16. 


IPsec L2L Config 


TNT 06-2 


(BFC) 


the efforts 
experiments 


o 

in 


(6) Avon Park. As a ma 
f TNT/CENETIX, the abili 
the field allows SOCOM to 


jor contributor 
ty to observe 
participate. 


to 

the 
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Figure 17. 


IPsec L2L Config TNT 06-2 (Avon Park) 


(7) MSC NSWC. As a major contributor to 
the efforts of TNT/CENETIX, the ability to observe the 
experiments in the field allows Naval Special Warfare 
Command to participate. 


m 


sms 


amsmn 


Modify an IPSec LAN-to-LAN connection 

Enable 0 
Name MSC NSWC 

Inteifar e Ethernet 2 (Public) (205155 71 182) ’ 
Connection Type Br-directionol v 
144.141.185.2 


Check to enable tbs LAN-to-LAN connection 

Enter die name for this LAN-to-LAN connection 

Select the interface for this LAN-to-LAN connection 

Choose the type of LAN-to-LAN connection An Originate-Only 

connection may have multiple peers specified below 


Enter the remote peer IP addresses for das LAN-to-LAN 

Peers connection OnginaM-Oniy connection may specify up to ten peer 

IP addresses Enter one IP address per line 


,, None (Use Preshored Keys) v 

Ceitificate - 

Ceitificate O Entire certificate chain 
Transmission © Identity certificate only 
Piesliaied Key M563WI5556344qqA 
Authentic ation ESP/SHA/HMAC-160 v 
Encryption 3DES-168 v 
EKE Pioposal IKE-3DES-MD5 j 


Select the digital certificate to use 

Choose how to send the digital certificate to the IKE peer 

Enter die preshared key for this LAN-to-LAN connection 

Specify the packet authentic abon mechanism to use 

Specify the encryption mechanism to use 

Select the IKE Proposal to use for this LAN-to-LAN connection 


Figure 18. IPsec L2L Config TNT 06-2 (MSC). 


jb. Observations 

Initially observations for both Camp Roberts and 
Coast Guard station Alameda were going to be monitored by 
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use of SolarWinds and the VPN 3000 Concentrator Series 
Manager. However, we could not meet the requirements for 
this experiment to install a dedicated line for the VPN 
connection to CGSA during TNT -6-2. 

With the VPN 3000 Concentrator Series Manager 
multiple views and the ability to make changes via a web- 
enabled interface is possible. Because CENETIX Lab is 
operated by students and faculty, a GUI interface is ideal 
for the management of the VPN device. This proved vital 
for our observations; until SNMP was enabled then we could 
start using SolarWinds to monitor the VPN status, on a 
limited scale. 

By typing in the nps_tnt06_vpn Concentrator IP 
Adx of 131.120.0.10, we were authorized minimal privileges 
to view the system configuration and monitoring tools. 
This access is granted from those administrators who are 
authorized to add users and grant privileges. Authorized 
users can then access the VPN 3000 Series Manager via a 
HTTPS (preferred) or HTTP (which will then ask if you would 
like to install SSL certificate) connection from a web 
browser. During my observations both Internet Explorer 6.0 
and Mozilla Firefox 1.5.0.6 browsers were utilized without 
any problems. 


38 




Figure 19. Cisco 3015 Log-In Screen 


This Series Manager allows many valuable quick 
observation tools for the network administrator to remotely 
(or locally) view the VPN Concentrator, and make quick 
adjustments to the configuration if necessary. This tool 
was predominantly used during TNT 06-2 and 06-3, and 
allowed easy management of L2L sites as well as remote user 
account management. Furthermore, this tool provided a 
means for monitoring the log files which provided valuable 
insight during troubleshooting. The figure below is the 
initial screen which allows management of three main areas 
of operations: Configuration, Administration, and 
Monitoring. 
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(SHbiIiiUi 

Wricotnf to the VPN 1000 Concentrator Managf-t 


In tbe left borne « die aovwoaon tor oteve. ckk die funcooa you wont 

• C---:ilL.-u •• to configure all features of tfau device 

• AAnurtitroaon to control admauttrative functions on das device 

• M:ratonrjt - - to view statu, itotutics. and logs on this device 

The bos at the top sight has 

• Mam to return to this screen 

• Help -- to get help for tbe current screen 

• Suwtsi • to occtn VPN 3000 Cooceafroiot support and documentation 

• Ivjj*® - to log out of tins session on-i return to tbe Manager logo screen 

Under the location bar in the upper sight, these items may appear Click to: 

• Save kJ — save the active ccofi^iraoon and make a the boot configuration 

• Save Needed Q - as above, mdscasng you have changed the active configuration 

• Reset d? to teniporaedy reset statistics to zero 

• Restore ^ to restore statistics from die* reset values 



Figure 20. 


Cisco 3015 Concentrator Manager 


The Top 10 Lists provide the following data for 
Network Managers to evaluate performance (shows statistics 
for the top 10 currently active VPN Concentrator sessions) 
sorted by data, duration and throughput. Administrators 
would find the session transmitting the most data, and the 
session that has been connected the longest to be the most 
useful information. The figures below represent the actual 
data collected during TNT 06-2: 

(1) Data. Represents the amount of data 
transmitted since the user connected, this is not an 
average rate, which unlike SolarWinds can be determined 
(Fig-37). 
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Figure 21. 

Series 

Manager Top 

Ten 

(Data) 

(2) 

Duration. 

The amount 

of 

time a session 


has been active. 




Top Ten user* in Group —AJI— v based on Duration as of 02/28/200$ 100844 


Username 

Group 

IP Addr ess 

IVotocol 

Encryption 

Login Tune 

Diu ation 

150 177 145 130 

150 177 145 130 150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

02/24/2006 ~ 

14 11:59 

[3d 

195900 

148 70 235 27 

14870 235 27 

148 70 235 27 

IPSec/LAN-to-LAN 3DES-168 

02/28/2006 

083922 

131:37 

rroth 

NPSTNT06VPN 

17216 1 1 

IPSec/NAT-T 

3DES-168 

02/28/2006 

0903:21 

107:38 

user 

N/A 

172 20 145 228 

HTTP 

3DES-168 

|TLSvl 

02/28/2006 

1007 19 

003:40 


Figure 22. 


Series Manager Top Ten 


(Duration) 
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could be used in 
bandwidth. 
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average throughput 
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Top Ten user* in Group —AJI— v based on Tluoughpnt as of 02/28/2006 10 10:59 


Usnnanf 

Group 

IP Address 

Protocol 

Encryption 

Logui Tune 

Avg. 

Tlu ougltpitt 

(bytes sec) 

rroth 

NPSTNT06VPN 

172 161 1 

IPSec/NAT-T 

3DES-168 

(02/28/2006 

0903:21 

432 

1487023527 

14870 235 27 

14870 23527 

IPSec/LAN-to-LAN 

CO 

'O 

1 

02/28/2006 

08 3921 

381 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to-LAN 

CO 

UL 

02/24/2006 

14 1158 

13 

user 

N/A 

172 20 145 228 

HTTP 

3DES-168 

fHS»l 

|02/28/2006 

100718 

N/A 


Figure 23. Series Manager Top Ten (Throughput) 


(4) Final Checks, 28-Feb-06. During the 
final installations and configurations for TNT 06-2, both 
the BFC (150.177.145.130) and Avon Park (148.70.235.27) 
connections initiated a successful session. However, the 
MSC connection failed due to firewall settings at Coronado 
Network Operations Center. Coordination between the MSC 
and their immediate NOC was occurring during this time, and 
success was not achieved until late afternoon on 28Feb06 
(Fig-29) . The main problem that impeded MSC from 

successfully establishing a L2L IPsec VPN tunnel was that 
the Access Control Lists (ACLs) were not allowing IPSec 
traffic to tunnel through. 


[:miFTimM I 111 IK 11( 111 ll»i 1! l-l.ll 

[tcfr rshtjb 

Top Ten users in Group -AIK v based on Data as of02/27/2006 10 25 15 


Useiuaine 

Group 

IP Address 

Plolorol 

Encryption 

Logui Tune 

Total 

Bstes 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

02/24/2006 

14 1159 

4425072 

148 70.235.27 

14870 23527 

14870 235 27 

IPSec/LAN-to-LAN 

3DES-168 

02/28/2006 

083922 

1908400 

rroth 

NPSTNT06VPN 

172 16 1 1 

IPSec/NAT-T 

3DES-168 

02/28/2006 

0903 21 

1554312 

user 

N/A 

172 20 145 228 

HTTP 

3DES-168 

TLSvl 

02/28/2006 

10:0719 

N/A 


Figure 24. TNT 06-2 Pre-Check (Data) 
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mitorlng | Sessions I Top Ten lists I Oumlion 


Tuesdiy. 29 February 2006 10:10:59| 


Refresh^ 

Top Ten users in Gioup -AH- v based on Dotation as of 02/28/2006 100844 


Username 

Gioup 

IP Address 

Protocol 

Encryption 

Login Tune 

Duration 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

02/24/2006 
[14:1139 | 

3d 

195900 

148 70 235 27 

14870 235 27 

148 70 235 27 

IPSec/LAN-to-LAN 

3DES-168 

02/28/2006 

083922 

13137 

noth 

NPSTNT06VPN 

172 16 1 1 

IPSec/NAT-T 

3DES-168 

02/28/2006 

09 0321 

107 38 

user 

N/A 

172 20 145 228 

HTTP 

3DES-168 

TLSvl 

02/28/2006 

100719 

00340 


Figure 25. TNT 06-2 Pre-Check (Duration) 
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Ten lists | Throu 


?006 10:11:14 


Rofii'sli<S> 


Top Ten users in Group -Ait- •* based on Tlu oujhpnt as of 02/28/2006 10 10 59 


Username 

Group 

IP Address 

ftotocol 

Encryption 

Logui Tune 

Avg 

Tluoughput 
(bytes sec) 

rroth 

NPSTNT06VPN 

172 16 1.1 

IPSec/NAT-T 

3DES-168 

02/28/2006 

09 03 21 

432 

148 70 235 27 

14870 235 27 

148 70 235 27 

IPSec/LAN-to-LAN 

OO 

L§_ 

02/28/2006 

08 3921 

381 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

02/24/2006 
141158 _| 

13 

user 

N/A 

172 20 145 228 

HTTP 

3DES-168 

TLSvl 

02/28/2006 

1007 18 

N/A 


Figure 26. TNT 06-2 Pre-Check (Throughput) 


This section of the Manager lets you view 
statistics that are recorded in standard MIB-II objects on 
the VPN Concentrator. MIB-II (Management Information Base, 
version 2) objects are variables that contain data about 
the system. They are defined as part of the Simple Network 
Management Protocol (SNMP); and SNMP-based network 
management systems can query the VPN Concentrator to gather 
the data. However, the 3000 Series Manager can not "walk" 
the hierarchical MIB tree; a few of the VPN MIB-II 
variables were walked by using SolarWinds, once SNMP was 
enabled (see Fig-43, 44). One statistic of interest for my 
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observations is shown in Fig-25; this screen shows the 
statistics of the MIB-II objects for IP traffic on the VPN 
Concentrator since it was last booted or reset, prior to 
28Feb06. For a more specific IP MIB object definition refer 
to RFC 2011. The Series Manager allows for monitoring of 
up to nine different objects. The items of interest 
include: Packets Received (Total), Packets Received 
(Discarded), Packets Received (Delivered), Packets 
Forwarded, Outbound Packets with No Route, Packets 
Transmitted (Requests), Fragments Needing Reassembly, 
Reassembly Successes, Fragmentation Successes, Fragments 
Created. These items are discussed in more detail below. 


(CP-II, 226-227) 



1J Mill 


Resell Refresh^ 


Packers Received (Total) 

1104643 

Packers Received (Headei Errors) 

57 

Packers Received (Address Fuois) 

0 

Packets Recess ed (Unknown Protocols) 

0 

Packers Received (Discarded) 

0 

Packers Received (Delivered) 

809497 

Packers Forwarded 

281329 

Outbound Packets Discarded 

0 

Ontboimd Packets with No Rome 

1071 

Packets Tr ansinrtted (Requests) 

74543 

Fragments Needmg Reassembly 

22 

Reassembly Successes 

11 

Reassembly Failures 

0 

Fragmentation Successes 

31 

Fragment anon Failtues 

0 

Fragments Created 

62 


Figure 27. Series Manager MIB-II IP Stats 


Packets Received (Total) — the total number of IP data 
packets received by the VPN Concentrator, including 
those received with errors. 
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Packets Received (Delivered) — the number of IP data 
packets received and successfully delivered to IP user 
protocols (including ICMP) on the VPN Concentrator; 
i.e., the VPN Concentrator was the final destination. 

Packets Forwarded — the number of IP data packets 
received and forwarded to destinations other than the 
VPN Concentrator. 

Outbound Packets with No Route — the number of 
outbound IP data packets discarded because no route 
could be found to transmit them to their destination. 
This number includes any packets that the VPN 
Concentrator could not route because all of its 
default routers are down. 

Packets Transmitted (Requests) — the number of IP data 
packets that local IP user protocols (including ICMP) 
supplied to transmission requests. This number does 
not include any packets counted in Packets Forwarded. 

Fragments Needing Reassembly — the number of IP 
fragments received by the VPN Concentrator that needed 
to be reassembled. 

Reassembly Successes — the number of IP data packets 
successfully reassembled. 

Reassembly Failures — the number of failures detected 

by the IP reassembly algorithm (for whatever reason: 

timed out, errors, etc.) . This number is not 

necessarily a count of discarded IP fragments since 
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some algorithms can lose track of the number of 
fragments by combining them as they are received. 

Fragmentation Successes — the number of IP data 
packets that have been successfully fragmented by the 
VPN Concentrator. 

Fragmentation Failures — the number of IP data packets 
that have been discarded because they needed to be 
fragmented but could not be fragmented (for example, 
because the Don't Fragment flag was set). 

Fig-26 through Fig-28 indicates the Session 
Details for the active sessions during TNT 06-2. Use of 
this screen was important in order that one view of the 
critical circuit details, both parameters and statistics, 
could be viewed. 

I'FTTirrlJI.MHi III.! H ■'*<1J IIM l.'KIimTS?} 

Resell Rirfr 


Back to Sessions 


Connection Name 

EP Address 

Aotocol 

Fnciypfion 

Login Time 

I>tu ation 

Bytes Tx 

Bytes Rx 

AVON PARK VPN 

148 70 235 27 

IPSec/LAN-to-LAN 

3DES-168 

Feb 28 08 39 21 

305 10 

9933968 

6979184 


IKE Sessions: 1 


IPSec Sessions: 1 


IKE Session 

Session H) 

1 Encryption Algorithm 3DES-168 

Hashing Algorithm 

MD5 

DifHe-Hellman Group Group 2 (1024-bit) 

Authentication Mode 

Pre-Shared Keys 

IKE Negotiation Mode Mam 

Rekey Time Inteival 

86400 seconds 

IPSec Session 

Session ID 

2 

Remote Address 10 217 220.0/0 0 0 255 

Local Addi ess 

192 168 64 0/0 0 63 255 

Encryption .Algontlun 3DES-168 

Hashing .Algontlun 

MD5 

Encapsulation Mode Tunnel 

Rekey Tone Inteival 

28800 seconds 


Bytes Received 

6979184 

Bytes Ti ansmirted 9933968 


Figure 28. Manager Session Details (Avon Park) 
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Sessions | Detail 


■ I Id M.H l.'KiffWgTPI 

Resell Refresh(§> 


Back to Sessions 


Connection Name 

IP Addiess 

Protocol 

Enciyption 

Login Tune 

Dui ation 

Bytes Tx 

Byte* Rx 

Army Biolab Tunnel 

150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

Feb 24 14 1204 

3d 21:32:59 

2195088 

2504256 


IKE .Sessions 1 
IPSec Sessions: 1 


IKE Session 

Session U) 

i 

Enciyption Algontlun 3DES-168 

Ha slung Algontlun 

MD5 

Diffie-Heilman Gioup Group 2 (1024-bit) 

Authentic anon Mode 

Pre-Shared Keys 

IKE Negotiation Mode Mam 

Rekey Tune Inters al 

28800 seconds 

IPSec Session 

Session II) 

2 

Remote Addless 150 177 195 5 

Local Address 

192 168 64 0/0 0 63 255 Encryption Algontlun 3DES-168 

Haslung Algol itlun 

MD5 

Encapsulation Mode Tunnel 

Rekey Tune Inteival 

3600 seconds 

Rekey Data Interval 4608000 KBytes 

Bytes Received 

2504256 

Bytes Transmitted 2195088 


Figure 29. Manager Session Details (BFC) 


Detail_Toiday. 28 February 7006 15:16:07 


Reset & Reft esh®^ 


Back to Sessions 


(.'onuethou Name 

IP Addiess 

Piotocol 

Emiy)>non 

LogmTune 

I>iu anon 

Bytes Tx 

Bytes Rx 

MSCNSWC 

144 141 1852 

IPSec/LAN-to-LAN 

3DES-168 

Feb 28 1448 56 

027 11 

251352 

175856 


IKE Sessions: 1 
IPSec Sessions: 1 

IKE Session 


Session ID 

1 Enciyption Algontlun 3DES-168 

Hashing Algontlun 

MD5 

Diffie-Hellinan Group Group 2 (1024-bd) 

Authentication Mode 

Pre-Shared Keys 

IKE Negotiation Mode Man 

Rekev Tune Inreival 

86400 seconds 

IPSec Session 

Session ID 

2 

Remote Addiess 172 18 1 0/0 0 0 255 

Local Addi ess 

192 168 64 0/0 0 63 255 

Enciyption Algonthm 3DES-168 

Hashing Algontlun 

SHA-1 

Encapsulation Mode Tunnel 

Rekey Tune Inreival 

28800 seconds 

Bytes Received 

175856 

Bytes Transmitted 251352 

Figure 30. 

Manager 

Session Details (MSC) 
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(5) Experiment 5, Scenario 1, 28-Feb-06. 


LAN to LAN Sessions 


[ Remote Access Scsst:: | 


Connection Name 

IP Address 

Protocol 

Enciyptiou 

Logui Tune 

Dm atnj 

Bytes Tx 

Bytes Rx 

AVON PARK 

|VPN 

148 70 235 27 

PSec/LAN-to-LAN 

3DES-168 

Mar 1 11 50 23 

0 02 5 

11096 

49528 

Aimv Biolab Tunnel 

150 177 145 130 

PSec/LAN-to-LAN 

3DES-168 

Mar 1 74342 

4 09 3> 

4351848 

1152496 

MSC NSWC 

144 141 185 2 

PSec/LAN-to-LAN 

3DES-168 

Feb 28 
144856 

21 04 2 

1472136 

S_ 

301232 


\ 


Remote Access Sessions [ LAN-to-LAN Sessions | Management Sessions ] 



Assigned P 


Piotocol 

Encivntiou 

Logui Tune 
Duration 

Client 

f 


A<' Result 

Useinaine 

Addi ess 

Group 

Tvne 


Bvtes Rx 

Posnue 


Public IP Addi ess 


Veisioi 


Token 

■rmth 

172 16 1 1 

MPsmjmAVPM 

PSec/NAT-T 

Mar 1 
inv?4Q 

WtnNT 

1179552 

MCA 


Figure 31. TNT 06-2 Observations (28Feb06) 


; Statistics | MIB-II | IP_Tuesday. ?8 1 ebmaty ?00S 15:33:.M 


Resell Roll i , sli<3> 


Packets Received t Total) 

1292202 

Packets Received (Headei Fnors) 

53 

Packets Received 1 Addi ess Fnors) 

°l 

Packets Received (Unknown Piotocols) 

0 

Packets Received (Discaided) 

0 

Packets Received (Debveied) 

855391 

Packets Forwarded 

f420575 

Outbound Packets Discarded 

0 

Outbomid Packets with No Route 

1299 

Packets Tiansmitted (Requests) 

f 86926 

Fi agments Needuig Reassembly 

5534 

Reassembly Successes 

2767 

Reassembly Failuies 

o] 

Fi alimentation Successes 

2707 

Fi agmentation Failtu es 

0 

Fi agmeuts Created 

5414 


Figure 32. TNT 06-2 Observations (28Feb06) 
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(6) Experiment 5, Scenario 2, l-Mar-06 




Top Ten users in Gi oup -Alt- 

v based on Data as of02/28/2006 15 52 29 



Username 

Group 

IP Address 

Protocol 

Encryption 

Logui Tune 

Total 

Bytes 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

03/01/2006 

074342 

6488832 

148 70 235 27 

14870 235 27 

148 70 235 27 

IPSec/LAN-to-LAN 

3DES-168 

03/01/2006 

11 5023 

4724648 

troth 

NPSTNT06VPN 

172 16 1 1 

IPSec/NAT-T 

3DES-168 

03/01/2006 

10 57 49 

1938208 

144 141 185 2 

144 141 185 2 

144 141 185 2 

IPSec/LAN-to-LAN 

3DES-168 

02/28/2006 

144854 

1790216 

user 

N/A 

172 20 146 182 

HTTP 

3DES-168 

TLSvl 

03/01/2006 

1209 58 

N/A 


Figure 33. TNT 06-2 Observations (!Mar06) 


i mi | n \ 111| | 111|11 | 
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Top Ten user* in Group —AJI— v based on Tluoughput as of03/01/2006 12 10 08 


Username 
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IP Address 

Protocol 

Encryption 

Logui Tune 

Avg. 
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tbytes sec > 

148 70 235 27 

148 70 235 27 

148 70 235 27 

IPSec/LAN-to-LAN 

3DES-168 

03/01/2006 

11 50 24 

4011 

rroth 

NPSTNT06VPN 

172161 1 

IPSec/NAT-T 

3DES-168 

03/01/2006 

10 57 49 

445 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to-LAN 

3DES-168 

03/01/2006 

074342 

404 

144 141 185 2 

144 141 185.2 

144 141 185 2 

IPSec/LAN-to-LAN 

3DES-168 

02/28/2006 

144855 

23 

user 

N/A 

172 20 146 182 

HTTP 

3DES-168 

TLSvl 

03/01/2006 

12 09 58 

L - ™ 


Figure 34. TNT 06-2 Observations (!Mar06) 
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* Cisco Systems, Inc. VPN 3000 Concentrator [tnt06vpn] Mozilla Firefox 




Configuration I Administration I Monitoring 


NAC' Session Summary 
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Rejected 

Exempted 

Noil-responsive 

Hold off 

N/A 

Active 
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Active 
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Active | Total 

r ° 
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0 

1 0 

0 
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0 

1 0 

f 0 

0 

1 1 f 10 


Connection Name 

DP Address 

Protocol 
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Diu ation 
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Bytes Rx 

AVON PARK 

VPN 

148 70 235 27 

IPSec/LAN-to-LAN 

3DES-168 

Marl 115023 

0 02 55 

11096 

49528 

Armv Biolab Tunnel 

1150 177 145 130 

PSec/LAN-to-LAN 

3DES-168 

Mar 1 74342 

4 09 36 

4351848 

1152496 
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144 141,185,2 

PSec/LAN-to-LAN 

3DES-168 

Feb 28 
144856 

2104 24 

1472136 

301232 


Remote Access Sessions 


f LAN-to-LAN Sessions | Management Sessions 1 


Cist# SrsttiJ 

Assigned IP 

Username Address 

Public IP Address 

Protocol 

1 ‘ Enrrvntton 

Login Time 
Dtuahou 

Client 

Tvpe 

Version 

Bvtes Tx 

Bvtes Rx 

NAC Result 

Posnue 

Token 

WKKM. 

172.16.1.1 


Mar 1 

WinNT 

1179552 



Figure 35. 


TNT 06-2 Observations (!Mar06) 


06 


(7) Experiment 5, Repeat Scenario 2, 2-Mar- 


Reset 4 ^ Refresh^ 


This screen shows statistics for sessions To refresh the statistics, click Refresh Select a Gioup to filter the sessions For more 
information on a session, click on that session's name 


LAN-to-LAN Sessions 


( Remote Access Sessions | 




Connection Name 

IP Address 

Rotocol 

Enciyption 

Logui Tune 

I 'HI ilj.>li 

AVON PARK VPN 

148 70 235.27 

IPSec/LAN-to- 

LAN 

3DES-168 

Mar 2 7 30 55 

2 22 59 

Armv BioUb Tunnel 

150 177 145 130 

IPSec/LAN-to- 

LAN 

3DES-168 

Mar 1 74342 

2b n i;. 

MSCNSWC 

144 141 185 2 

IPSec/LAN-to- 

LAN 

3DES-168 

Feb 28 
144856 



anagement Sessions J 




955216 5940296 
15880040 4191296 


J 


Figure 36, 


TNT 06-2 Observations (2Mar06) 
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Username 

Group 

IP Address 

Protocol 

Enciyp tion 

Login Tune 


Total 

Bytoi 

144 141 185 2 

144 141 185 2 

144 141 185 2 

IPSec/LAN-to- 

LAN 

3DES-168 

02/28/2006 

144853 


30930824 

150 177 145 130 

150.177 145 130 

150 177 145 130 

IPSec/LAN-to- 

LAN 

3DES-168 

03/01/2006 

07 4 3 40 


20095763 

148 70 235 27 

148 70 235 27 

148 70 235 27 

IPSec/LAN-to- 

LAN 

3DES-168 

03/02/2006 

07 30 54 


6949696 

user 

N/A 

172 20146 182 

HTTP 

3DES-168 

SSLv3 

03/02/2006 

09 50 10 


N/A 

user 

N/A 

172 20146182 

HTTP 

3DES-168 

SSLv3 

03/02/2006 

095347 


N/A 










Figure 37. TNT 06-2 Observations (2Mar06) 
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Username 

Group 

IP Address 

Protocol 

Encryption 

Logui Tune 

Avg. 

Tlu ougliput 

tbytes see) 

148 70 235 27 

148 70235 27 

148 70 235 27 

IPSec/LAN-to- 

LAN 

3DES-168 

03/02/2006 

07 30 54 

764 

144 141 185 2 

144 141 185 2 

144 141 185 2 

IPSec/LAN-to- 

LAN 

3DES-168 

02/28/2006 

1448 53 

214 

150 177 145 130 

150 177 145 130 

150 177 145 130 

IPSec/LAN-to- 

LAN 

3DES-168 

03/01/2006 
074340 

212 

user 

N/A 

172 20 146 182 

HTTP 

3DES-168 

SSL«3 

03/02/2006 

09 5348 

N/A 


Figure 38. TNT 06-2 Observations (2Mar06) 


• A limited amount of observations were made using 

SolarWinds Network Management Tool; due to the 
administrative limitations imposed on students 
and staff by NPS ITACS. The use of SolarWinds in 
capturing the movement of data packets, network 
failures, and various other administrative 

measures in future has been mitigated due to 
submission of a Change Configuration Board 
Request dated 27-Feb-06 and subsequent approval 
on 6-Mar-06. This request gave administrative 
control to the CENETIX personnel for future 
changes, in the daily operation and preparation 
of future TNT experiments. 

• Once SNMP was enabled, via ITACS assistance, we 

could then track Network Performance through use 
of SNMP. The following figures were gathered 

during TNT 06-2, and focused primarily on the 
measurement of traffic across the link. 
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VPN NPS 131.120.0.10 

Min)Max/Average bps of Recv 100 Mbps Xmit 100 Mbps 

Last 7 Days 

MinMax Receive bps MinJMax Transmit bps Average Receive bps Average Transmit bps 







'i 










i_i_i_i_i_i 

Li 

i 

24 Fri 25 Sat 26 Sun 27 Mot 28 Tue Mar 2 Thu 3 Fri 

Min/Max Receive bps 
Min/Max Transmit bps 
Average Receive bps 
Average Transmit bps 

0.42 4.72 0.14 

0.98 320.61 0.46 

0.39 0.83 0.13 

0.93 35.94 0.43 


Figure 39. TNT 06-2 Solar Wind Observations- Avg bps 



VPN NPS 131.120.0.10 

MinMax/Average packets per second 

Last 7 Days 

Min/Max Receive pps Min/Max Transmit pps Average Receive pps Average Transmit pps 
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24 Fri 25 Sat 26 Sun 27 Mot 28 Tue Mar 2 Thu 3 Fri 

Min/Max Receive pps 
Min/Max Transmit pps 
Average Receive pps 
Average Transmit pps 

0.33 4.91 0.11 

0.76 46.35 0.32 

0.32 0.79 0.10 

0.73 5.51 0.30 
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TNT 06-2 Solar Winds Observations - Avg pps 



































VPN NPS 131.120.0.10 

Total Packets Every 2 Hours 
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24 Fri 25 Sat 26 Sun 27 Mon 28 Tue Mar 2 Thu 

3 Fri 

Received 

2.26 

5.71 0.27 1 

Transmitted 

5.09 39.82 0.81 


Figure 41. 


TNT 06-2 Solar Winds Observations - Total 
Packets 


2. Recommendations 

a. SNMP Configuration 

Prior to the start of TNT 06-2 SNMP was not 
enabled, due to administrative constraints imposed by NPS 
ITACS. This restriction is enforced by ITACS to prevent 
students, who participate in this environment, from making 
unauthorized changes. On multiple occasions requesting 
SNMP to be enabled on the TNT VPN device was ignored, 
however ITACS ultimately enabled SNMP which allowed the 
CENETIX NOC to use SolarWinds in network monitoring of the 
VPN circuit on a limited scale. 




This section lets you configure SNMP community strings 

Community Strings Actions 

public 


1 **» I 

| Modrty | 

[ Delete | 


Figure 42. SNMP Manager Setting 
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b. Routing Tables 

Problem statement: The BFC lost connection to 
the VPN, on 2-Mar-06, after a change to the Avon Park 
circuit. It is believed that the BFC could not gain access 
due to a problem with the routing table or ACL's. 


M.i.iii.iiu uimgHiwit 


! Static Routes 


Tbs section lets you configure static routes for IP routing 


Routing problem... 


Save 0 


.Static Routes 


Default -> 205 155 71 177 
172.20.0 0/255 255 0 0 -> 131 120 0 200 
192 168 99 0/255 255 255 0 -> 131 1200107 
131.120 200 0/255 255 252 0 -> 131 120.0.110 
131 120176 0/255 255 2520 -> 131 120 0107 


Actions 


| Add 1 

( Modify | 

[ Delete | 




m | IP Routing I Static Route. 


SavoQ 


Tbs section lets you configure static routes for IP routing Routing problem corrected... 

Actions 


Add | 
[ Modify | 

| Delete ] 


Static Route. 

Deloult->205 155 71 177 
172 20 0 0/255 255 0 0 -> 131 120 0 200 
192160 64 0/255 255192 0 -> 131 120 0107 
131 120 200 0/255 255 252 0 -> 131 120 0110 
131 120176 0/255 255 252 0 -> 131 120 0 1 07 


Figure 43. 3015 Static Route Table 

Problem Resolution: This was required because 

all the 131 range of IPs was striped off of the ACL's, in 
order that the BFC could gain access to the CENETIX 
network. I believe this problem was caused by when Avon 
Park was configured for access on the concentrator. 
c. Security Association (SA) 

• A security association contains all of the 
information necessary for implementing the 
security services for a connection, such as the 
use of AH and ESP, the connection mode (tunnel or 
transport), the HMAC functions and encryption 
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algorithms, the keys to use for these functions 

and algorithms, the lifetime of the SA, and many 

other items. 

• RFC 2402 - Authentication Header (AH) 

performs three main functions: data 

integrity services, data authentication, and 
protection against data replay attacks. 

• AH protects the entire packet with the 

exception of TTL and TOS fields in the IP 
header. 

• AH is a protocol like IP, ICMP, TCP and UDP. 
It is assigned the protocol number 51. 

• RFC 2406 - Encapsulation Security Protocol 

(ESP) performs the same services as AH, but 
with two exceptions. 

• ESP is a protocol like IP, ICMP, TCP and 

UDP. It is assigned the protocol number 50, 
and it layer Layer-3 protection of data. 

• Provides encryption of the user data. 

• ESP's data authentication and integrity 

service only include the ESP header and 
payload - so if someone modified the ESP 
payload, ESP wouldn't detect it, whereas AH 
would. 

• For both the MSC and BFC we experienced 

problems with the Security Association piece 
of VPN. SA is basically a group of the 

necessary security components to 

successfully build a secure connection with 
an IPsec peer. VPNs accomplish this 

security process through two separate phases 
which it must successfully negotiate in 
order to construct a secure tunnel using 
IPsec. 

• What may have caused this to fail during the 
site-to-site (L2L) VPN connection could have 
been caused by the Perfect Forward Secrecy 
was enabled. With this being set it caused 
a Phase 2 authentication failure with the SA 
IPsec proposals. 
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[Configuration | Policy Management | Traffic Management 1 Security Associations | Modify 


Modify a configured Security Association. 

S A N aine L2L: Army Bio lab Tunnej Sp e cify the name of this S e curity As s o ciation (S A). 

Inheritance From Rule v Select the granularity of this S A. 


IPSec Parameters 
Authentication 
Algorithm 
Encryption 
Algoiitlun 
Encapsulation . 
Mode 

Perfect Forward ^ 
Secrecy L 
Lifetime . 
Measurement 
Data Lifetime 1 


ES P/M D5/H MAC-128 ' 


Time Lifetime 28800 


Select the packet authentication algorithm to use. 
Select the ESP encryption algorithm to use. 

Select the Encapsulation Mode for this SA. 

Select the use of Perfect Forward Secrecy. 

Select the lifetime measurement of the IPSec keys. 
Specify the data lifetime in kilobytes (KB). 

Specify the time lifetime in seconds. 


Figure 44. 3015 Perfect Forward Secrecy Setting 

3. Tracking the Cisco VPN MIBs 


Plans 

were 

made to track 

the following Cisco VPN 

MIBs 

during TNT 

06-2 

; it was not 

until near 

the end of 

the 

experiment 

when 

ITACS finally allowed 

CENETIX NOC 

the 

opportunity 

to 

enable SNMP 

on the 

Cisco 3015 

VPN 


Concentrator. 


Cisco 3000 Series Observed MIBs 


altiga.mi2 

v2 1 3 j 6.I 4.1 3076.1.1 3.1 ALTIOA-MIB (ALT1GA-MIB my) 


I2tp-stats.mi2 


vl 1361413076212*1 
v2 134.1 4.13076.1.1.13 2 
vl 13 6.1.4.130762 12.16.1 
v2 134.14.13076.1 .1212 


ALTIOA-1P-STATS-MIB (ALTIGA-IP-STAT$-M1B-V1$MI my) 
ALTIOA-IP-STATS-MIB (ALTICA-IP-STATS-WB my) 

ALTIQA-L2TP-STATS-M1B 
(ALT1GA-L2TP-STATS-MIB-V1SM! my) 

ALTIOA L2TP-STATS-MIB (ALTIGA-L2TP-STATS-MIB my) 


ipsec-flow.mi2 


vl 

136141994321 11 

CISCO-ENHANCED. T»J>4ar<W.MlB 
(CISCO-ENHAHCED-IPSEC-FLOW-MIB-VISM1 my) 

v2 

13j6.I 4.199432 

CISCO-ENHANCED-IPSEC-FLOW-M1B 

(CISCO-ENHANCED-IPSEC-FLOW-MIB my) 

vl 

13614199 171 1.1 

CISCO.15f35S3EW-MONITOR.MIB 

(CISCO-IPSEC-FLOW-MONITOR-MIB-V1SMI my) 

v2 

134.14.1.9.9.171 

CISCO-IPSEC-FLOW-MOHITOR-MIB 

(CISCO-IPSEC-FLOW-MONITOR-MIB my) 


Figure 45. MIB-II Variables (A Few) 
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a. Problem with Tracking MIBs 

On 3Mar06 CENETIX Lab; along with a significant 
portion of NPS lost power due to inclement weather. We had 
set SolarWinds to walk the MIB Trees for the above listed 
MIBs, but lost the track of data that SolarWinds would have 
captured for our use. The below is a depiction of what one 
MIB would have tracked (altiga.mi2). 


MIB Tree 


MIS 

OID Nare 

Value 


sysD-e&cr.Q 

Sisco Sysiers. mc-'VPM 300G Concentrator version *7.2 -3 Du It By vmurpny or Oct CM 2005 02:50:52 


sv&OBieaiDO 

i , DflConcentratoiRev2 

RFC1213-MB 

sysupTimeO 
sysCo ntact.0 

17days. 2i hours. 12minuies. 50 secords 


sysNameO 

irt 06 vpn 


aysLocatior a 


sysServlcesO 

76 


Figure 46. Solar Winds MIB-11 Tree 

4. Improvements to the TNT NOC 

• Isolate the TNT Private VLAN and VPN 

Concentrator; in order that students/staff can 
administer with minimal ITACS support. 

• Establish a class on SolarWinds/Orion and how to 
complete basic network management set-up, in 
preparation for TNT experiments and NOC student 
operations. 

• Develop a lesson on what the various charts and 

graphs those are available in SolarWinds/Orion, 
and what the data that is displayed means. 

• Incorporate a VTC between NOC-TOC at the 

beginning of the day, and end of the day in order 
that plans can be deconflicted or adjusted as 
needed. This way both the NOC and TOC understand 
the goals/results were for the day. 

• Develop Business Plans directing units who desire 
to operate on CENETIX network. 

• Ensure that CENETIX NOC has as many 

administrative privileges as possible without 
conflicting with ITACS policies. If 

authorization to make administrative changes 
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would be granted to a few personnel (Mike 
Clement, Eugene Boukarov, Dr. Bordetsky) they 
could make appropriate changes to the CENETIX 
Testbed, as required. 

B. TNT 06-3 

From 13-14 June 2006, NPS faculty and students 
continued experiments to evaluate the use of networks, 
advanced sensors, and collaborative technology for rapid 
Maritime Interdiction Operations (MIO); specifically the 
ability for a Boarding Party to rapidly set-up ship-to-ship 
communications that permit connectivity with C2 
organizations, and collaborating with remotely located 
sensor experts. 

The experiment extends the number of participating 
organizations beyond the TNT 06-2 MIO to include two 
international teams in Sweden and Austria, as well as the 
San Francisco Police Department (SFPD) and the Alameda 
County Marine Units. 

1. Architecture 

Although the number of participants who required a L2L 
connection decreased during this experiment, the use of VPN 
Clients increased, and the need for using NAT-T for the 
first time was implemented. In the below figure, CGSA 
required the use of a Netgear Router which afforded them 
the ability to provide a layer of security between the 
Internet and their end users (Fig-45). Because this 
scenario required NAT-T, constructing the circuit to port 
forward and tunnel through their ISP was required. This 
scenario although challenging, was validated prior to 
commencing TNT 06-3. 
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CENETIX TNT Network Architecture - Coast Guard Station Alameda 



Figure 47. CGSA - VPN Scenario. 


2. Configuration Details 

a. Network Topology: On-Site Infrastructure 

Over the past several iterations of 
experimentation, we have been implementing and utilizing 
VPN architecture for connecting the remote NOC at NPS, the 
local TOC and operational network in the Bay Area, and 

other interested parties such as LLNL and BFC participants 
in one private experimental network. This iteration, our 

communications requirements dictated the need for both a 
VPN connection in order to access NPS NOC resources and to 
allow for remote network monitoring via SolarWinds and 

similar tools, and a standard Internet connection in order 
to access the NPS-owned Groove server, providing the 

backend for our collaborative environment. 


Due to the learning curve in building site-to- 
site (L2L) VPN connections via NAT-T, we experimented with 
a number of topological options before finding the best fit 
for our circumstances at CGSA. Initially, we implemented 
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parallel 
provided 
and a T1 


connections over two distinct Internet connections 
at CGSA, utilizing a DSL connection for Internet 
for VPN. The initial topology was as follows: 


CENETIX TNT Network Architecture - CGSA - Initial 



All client computers in the primary local network 
had addresses of the form 192.168.72. xxx, with a 24-bit 
(255.255.255.0) netmask. Their default gateway was set to 
192.168.72.100, the address of the Linksys DSL router. The 
DSL router had static routes set to redirect VPN-bound 
traffic back through the local network to the Cisco 
concentrator and onward toward remote sites. This provided 
standard Internet connectivity as well as VPN connectivity 
for remote sites. The Netgear router provided a NAT 
service, and so we configured port forwarding for TCP and 
UDP ports 500, 4500, and 10, 000 to the public interface of 
the concentrator, in order to allow proper VPN 
functionality. 
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However, we experienced a number of problems with 
this configuration: 

• Address Conflicts: The Linksys DSL router was 
configured with a small DHCP segment in order to 
support USCG internal users on the same network. 
Before we established a preliminary IP plan, we 
were inadvertently assigning IP addresses that 
conflicted with DHCP addresses. 

• Redirect Overload: Since the default gateway 
specified for all nodes was the DSL router, it 
was responsible for reflecting all traffic 
destined for the VPN back into the local network 
toward the concentrator. This put additional 
stress on the router, and decreased overall 
network performance for both Internet and VPN 
access. 

• Unstable Platform: The DSL router, possibly due 
to the combination of the above afflictions, 
began to sporadically fail, requiring a full 
power cycle. This would happen as often as once 
every 10 to 15 minutes, resulting in a largely 
unusable configuration. The exact cause and 
prognosis were never determined. 

In order to solve these issues, we experimented 
with configuring the VPN concentrator itself as a normal 
Internet router, which turned out to be nearly its default 
configuration. The only lack of capability of the 
concentrator was to perform NAT, a function which was taken 
on by the Netgear router connecting the concentrator to the 
T1 line. By changing the default filters on the 
concentrator's public interface to allow all traffic 
through, it began to route standard Internet traffic as 
easily as it did VPN traffic. The resulting configuration 
was as follows: 
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CENETIX TNT Network Architecture - CGSA - Nat 



We changed every computer's default gateway to 
use 192.168.72.250, which resulted in all users utilizing 
the VPN concentrator to forward all traffic. This provided 
acceptable performance and stability for the remainder of 
the experiment. We also changed the VPN tunnel-able 
networks to include a broader range of IP addresses for 
additional subnets in the Bay Area, to cover more of the IP 
space dedicated to the NOC, and to support the range of VPN 
software clients. 

b. Network Topology: Global VPN Infrastructure 

Beyond the Bay Area infrastructure, we utilized 
VPN architecture to connect various experimental sites, 
including the NPS campus, Ulrich Wagner's team in Austria, 
and various one-off software clients, such as from LLNL. 
All connections terminated at NPS, which acted as the 
central relay point for all sites. We did not notice any 
performance drawbacks to this design; however, for future 
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performance and reliability concerns we could consider 
directly connecting all remote VPN sites to the Bay Area 
(i.e., Coast Guard Island) VPN concentrator. 

The global VPN infrastructure ultimately appeared 
as follows: 


CENETIX TNT Network Architecture - CGSA- Global 



"NCGS Alameda" 
3015 Concentrator 


Last Updated: 

13 July 2006 

Figure 50. CGSA - Global VPN Infrastructure. 

3. Observations 

Prior to TNT 06-3, several attempts were made to 
configure the Concentrator from my home (761CTNWD) and 
ultimately success was achieved once the port forwarding 
aspect of the router was configured. Attempting to 
simulate, as nearly as possible, the eguipment string that 
would be implemented at CGSA, the following architecture 
was tested. 
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CENETIX TNT Network Architecture - 761CTNWD - CGSA Testbed 



Figure 51. CGSA - Testbed from 761CTNWD. 


Using my Motorola Router, and my ISP Comcast, I was 
able to simulate the VPN configuration we would require for 
TNT 06-3 at CGSA. As stated earlier in Chapter II (IPsec 
and Firewalls), configuring NAT-T to tunnel through allowed 
a NAT-T connection to be established, as seen in the below 
figure. 

5(2 05/30/2006 14:00:17.200 SEV=5 IKE/66 RPT=33 67.188.63.68 

Croup [67.188.63.68] 

IKE Pemote Peer configured for SA: L2L: 761CTNWD_NPS 

563 05/30/2006 14:00:17.260 SEV=4 IKE/173 RPT=8 67.188.63.68 

Croup [67.188.63.68] 

NAT-Traversal successfully negotiated! 

IPSec traffic will be encapsulated to pass through NAT devices. 

566 05/30/2006 14:00:17.260 SEV=* IKE/49 RPT=33 67.188.63.68 

Croup [67.188.63.68] 

Security negotiation complete for LAN-to-LAN Croup (67.188.63.68) 

Responder, Inbound SPI = 0xl880aSe2, Outbound SPI = 0x3bl70Sac 

569 05/30/2006 14:00:17.270 SEV=4 IKE/120 RPT=33 67.188.63.68 

Croup [67.188.63.68] 

PHASE 2 COMPLETED <msgid=b3c6e837) 

Figure 52. NAT-T Log - Testbed from 761CTNWD. 
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During the experiment, the following observations were 


made: 
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Figure 53. L2L and Remote Connections TNT 06-3. 


|Monitoring 1 Sessions | Top Ten Lists | Data_Wednesday, 14 June 2006 14:25:32| 


Refresh 


Top Ten users in Group -All- v based on Data as of 06/13/2006 13:25:36. 


Username 

Group 

IP Addr ess 

Protocol 

Encryption 

Login Time 

Total 

Bytes 

67.109.22.21 67.109.22.21 

67.109.22.21 

IPSec/LAN-to- 

LAN/NAT-T 

3DES-168 

06/14/2006 

11:56:22 

279116744 

adougan4 

NPSTNT06VPN 

192.168.64.3 IPSec 

3DES-168 

106/13/2006 

12:11:41 

96335032 

adougan2 

NPSTNT06VPN 

192.168.644 

IPSec 

3DES-168 

06/13/2006 

12:33:52 

29099632 

adougan3 

NPSTNT06VPN 

192.168.64.1 

IPSec 

3DES-168 

06/14/2006 

10:31:52 

28695736 

adougan 

NPSTNT06VPN 

192.168.64.2 

IPSec 

3DES-168 

06/13/2006 

11:50:12 

635872 

farrellmm 

NPSTNT06VPN 

192.168.64.5 IPSec/NAT-T 

3DES-168 

06/14/2006 

14:19:38 

212624 

84 145.13.4 

84.145.13.4 

84.145.13.4 

IP S e c/LAN-to -LAN 

AES-128 

06/14/2006 

13:51:58 

168320 

admin 

N/A 

192.168.64.5 HTTP 

3DES-168 

SSLv3 

06/14/2006 

14:21:11 

N/A 


Figure 54. Data: Total Bytes TNT 06-3. 
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[Monitoring | Sessions 1 Top Ten Lists | Duration 


Wednesday, 14 June 2006 14:25:57| 


Refresh (£> 


Top Ten users in Group -All- v ) based on Duration as of 06/14/2006 14:25:32. 


Username 

Group 

IP Address 

Protocol 

Enciyptiou 

Login Time 

Duration 

adougan 

NPSTNT06VPN 

192.168.64.2 

IPSec 

3DES-168 

06/13/2006 

11:50:11 

26:35:46 

adougan4 

NPSTNT06VPN 

192.168.64.3 

IPSec 

3DES-168 

06/13/2006 

12:11:40 

26:14:17 

adougan2 

NPSTNT06VPN 

192.168.64.4 

IPSec 

3DES-168 

06/13/2006 

12:33:51 

25:52:06 

adougan3 

NPSTNT06VPN 

192.168.64.1 

IPSec 

3DES-168 

06/14/2006 

10:31:51 

3:54:06 

67.109.22.21 67.109.22.21 

67.109.22.21 

IPSec/LAN-to-LAN/NAT- 

T 

3DES-168 

06/14/2006 

11:56:21 

2:29:36 

84.145.13.4 

84.145.13.4 

84.145.13.4 

IPSec/LAN-to-LAN 

AES-128 

06/14/2006 

13:51:57 

0:34:00 

farrellmm 

NPSTNT06VPN 

192.168.64.5 

IPSec/NAT-T 

3DES-168 

06/14/2006 

14:19:37 

0:06:20 

admin 

N/A 

192.168.64.5 

HTTP 

3DES-168 

SSLv3 

06/14/2006 

14:21:10 

0:04:47 


Figure 55. Duration TNT 06-3. 


|Monitoring | Sessions | Top Ten Lists | Throughput_Wednesday, 14 June 2006 14:26:19| 


Refresh (§> 


Top Ten users in Group -All- v b ase d on Throughput as of 06/14/2006 14:25:32. 


Username 

Group 

IP Address 

Roto col 

Encryption Login Time 

Avg. 

Throughput 
(byte s/sec) 

67.109.22.21 

67.109.22.21 

67.109.22.21 

IPSec/LAN-to- 

LAN/NAT-T 

06/14/2006 

3DES468 | n:56:21 

31025 

adougan3 

NPSTNT06VPN 

192.168.64.1 

IPSec 

06/14/2006 

3DES-168 10:31;51 

2039 

adougan4 

NPSTNT06VPN 

192.168.64.3 

IPSec 

3DES-168 

06/13/2006 

12:11:40 

1019 

farrellmm 

NPSTNT06VPN 

192.168.64.5 

IPSec/NAT-T 

3DES-168 

06/14/2006 

14:19:37 

598 

adougan2 

NPSTNT06VPN 

192.168.64.4 

IPSec 

06/13/2006 

3DES-168 12:33;51 

312 

84.145.13.4 

84.145.13.4 

84 145.13.4 

IPSec/LAN-to-LAN 

AES-128 

06/14/2006 

13:51:57 

83 

adougan 

NPSTNT06VPN 192.168.64.2 

IPSec 

06/13/2006 

3DES468 | 11:50 . n 

6 

admin 

N/A 

192.168.64.5 

HTTP 

3DES-168 06/14/2006 

SSLv3 14:21:10 

N/A 


Figure 56. Average Throughput TNT 06-3. 


4. Recommendations 

Establish a proposed IP plan and network topology 

A comprehensive IP configuration for every anticipated node 

should be constructed, leaving space available for last- 

minute additions and changes. This includes not only node 

but the determination of subnetting 
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and 


































































gateway addresses. This listing should be distributed both 
via email prior to the experiment and by paper copy on the 
first day of configuration. Doing so not only enables all 
users to properly configure their nodes, but also to 
identify configuration problems and to allow shared 
knowledge of server and camera locations for easy access by 
users. 

Since this also will change as the experiment 
progresses, it is important to maintain the standard IP 
address webpage. This will ensure that all users have a 
common point of reference for double-checking their IP 
addresses, de-conflicting, and finding the address of a 
desired server. 
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IV. FUTURE CONSIDERATIONS 


A. FUTURE CONFIGURATION 

1. Test Operations of SSL for TNT 06-4 

Secure Socket Layer (SSL) began as a protocol to 
protect web-based (HTTP) traffic between an end-user device 
and a web server. However, in the case for the CENETIX Lab 
environment, it may be possible to implement SSL as a VPN 
solution for clients, with the main benefit being the 
software in the form of a web browser is already installed 
on client systems. 

Two main differences between IPsec and SSL are: IPsec 
provides protection for IP packets and protocols 
transmitted between networks or hosts. While SSL VPNs, 
provide protection for users' access to services and 
applications on a network. (Deal, 157) 

Because SSL VPN can typically support two methods of 
authentication: digital certificates, and username/password 
(or tokens), it is recommended that the later be utilized 
for clients who require SSL VPN connectivity. 


When making the final decision in utilization of SSL 
VPNs, the following table should be considered: (Deal, 167- 
168) 


Component 

SSL 

1 Psec 

Connectivity 

SSL only supports remote 

access 

IPsec supports both site-to-site and remote 

access 

Device 

authentication 

SSL supports digital 
certificates 

IPsec supports pre-shared keys, RSA encrypted 
nonces, and digital certificates 
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Component 

SSL 

1 Psec 

User 

authentication 

SSL supports user 
authentication 

IPsec supports user authentication through 

XAUTH unless it's L2TP/IPsec, in which case 
it's L2TP that is responsible for user 
authentication 

Protection 

SSL protects only the TCP 
payload and is thus 
susceptible to certain kinds 
of attacks 

IPsec can protect the user's data in a 
transport connection or an entire IP packet in 
tunnel mode 

Encryption 

SSL/TLS support RC2, RC4, 

IDEA, DES, 3DES, and AES; 
however most web browsers 
only support RC4, DES, and 
3DES 

IPsec supports DES, 3DES, and AES 

Message 

integrity 

SSL supports none except 
that provided by TCP 

IPsec supports MD5 and SHA-1 HMAC functions 

Implementation 

requirements 

SSL requires a web browser 
with Java/ActiveX installed 
for thin and network 
clients; because a web 
browser is used, most user 
operating systems will be 
supported 

IPsec requires an IPsec client installed or 
built into the operating system and configured 
on each user's desktop; because a special 
client must be installed, only operating 
systems supported by the vendor can use IPsec 

Transparency 

SSL has no problem with a 
session traversing an 
address translation device 
(NAT and/or PAT) 

IPsec has problems with AH traversing through 
any type of address translation device and ESP 
traversing a PAT device; however, IPsec is more 
likely to be denied by a firewall than a TCP 
port 443 (SSL) connection 

ISP issues 

Because SSL is commonly used 
on the Internet, ISPs don't 
block this kind of traffic 

Some ISPs block IPsec traffic and require users 
to pay an additional fee to use IPsec; you can 
get around this problem by encapsulating IPsec 
data in either a TCP or UDP segment, but this 
adds overhead to the transmission; this assumes 
that this process doesn't break the ISP's 
acceptable use policy (AUP) 

Table 2. 

SSL and IPsec 

Comparison. (From: Deal, 167- 


168) 
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2 . 


IP Plan 


The management of IP addresses has proven to be the 
most critical aspect piece of IT management, and it is no 
different in regards to the experiments that are operating 
within the CENETIX infrastructure. 

Currently the CENETIX testbed utilizes three subnets 
from the 192.168.0.0 private IP space. 

192.168.99. xxx CENETIX Lab 

192.168.100. xxx OFDM Backbone 

192.168.112.xxx Wireless ITT Mesh 

Device addresses are then managed via a few network 
administrators, and then displayed on the TNT website in 
order that network users can validate changes or additions. 

TNT Host IP 
configuration 

The following subnets are currently configured to support TNT experimentation: 

• Bay Area MIO 

• Bay Area Mesh 

• CENETIX Lah subnet 192.168.99.xx 

• OFDM backbone subnet 192.168.100.xx 

• Wireless ITT Mesh 192.168.112.xxx/25 ( mask 255.255.255.128) 


Fill in the following field(s) to match the search criteria: 

Host IP Node Name MAC address 

m 

Search 

Administration 

Figure 57. TNT Host IP Configuration 

In coordination with other CENETIX NOC Administrators 
an IP addressing scheme was derived for consideration in 
regards to future configuration changes. These changes 
would allow for a more logical approach to the overall 
management and operation of the CENETIX infrastructure. By 


Description 




NF OR MAT ION GRID 

GIGA 
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defining the third octet of the 192.168.x.x IP space, 
administrative control could be more easily accomplished as 
providing a level of scalability for changes in order that 
additional devices could be quickly and accurately added. 

The following recommendations are provided, in regards 
to IP address management: 



Figure 58. Proposed IP Address Management Scheme 


Secondly, utilizing DHCP more frequently would 
alleviate the burden of an administrator managing IP 
addresses as well as removing the human element of error 
when assigning IP addresses. It is realized that routers 
and switches do not generally use DHCP, but some automation 
may be utilized through the use of TFTP. However, with 
workstations the use of a DHCP server should dynamically 
assign addresses, and thus stored on a DNS server for the 
efficiency of the network. 

3. Purchase Additional 3000 Series Concentrators 
With the growth of CENETIX Lab in the past four years, 
and the number of organizations that desire to participate, 
the 3000 Series Concentrators provide the scalability that 
is required for L2L connections, which the CENETIX Lab 
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would require. Due to the ease of configuration 

management, versus a PIX or ASA router, students and 
faculty could more easily configure the device for future 
growth. With future purchases, it is also possible to 
configure the device prior to any exercise (locally), and 
then ship to the participating organizations who desire a 
L2L connection. 
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V. 


CONCLUSION 


The opportunity to work with the CENETIX Lab provided 
a capstone to my instruction at NPS. Finding a Thesis 
project that would incorporate both Information Technology 
and Management was crucial to my decision when choosing 
this thesis topic. 

The CENETIX Testbed has extended its reach beyond the 
Monterey Bay area and provided remote organizations a means 
to participate in experiments that will benefit the 
decision makers for those war fighters of the 21 st century. 
By providing a means in supporting organizations, such as 
SOCOM, LLNL, BFC, etc, the means to observe these 
experiments in a collaborative manner will only perfect the 
final outcome. 

Some of the questions that this thesis attempted to 
address when contemplating a VPN solution include: 

• What is the confidence level of the data you are 
sending? 

• What do I need to protect? 

• What kind of protection is required? 

• What value is placed on the secrecy? 

• How important is it to know the source of 
received data? 

• Is it scalable? 

• What is the cost? 

These questions only represent a very few that could 
be asked, but they do represent the more important 
questions that need to be addressed up front by those who 
manage and make decisions as an IT manager. 
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Furthermore, I attempted to address some of the major 
advantages of a VPN which include: Security, Deployment 
Advantages, and Cost Effectiveness. Of these, security is 
the most important IT requirement when considering and 
implementing in a VPN solution. As well as addressing the 
deployment advantages and cost effectiveness of a VPN 
solution, both from the economic advantages and ease in 
utilizing existing infrastructure in the installation of a 
VPN would be evident once the project was initiated. 

Lastly, by addressing the observations that were 
experienced during TNT 06-2 and 06-3, future operations of 
the Cenetix Lab VPN solution can evolve to better meet the 
needs of its primary customers during future experiments. 
Possible future solutions involve implementing an effective 
IP management plan, SSL Web VPN, and extending the Cenetix 
Lab via additional purchases of the Cisco 3000 Series 
Concentrator. 
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